문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 iPhone 5s (문단 편집) === 64-bit 지원 CPU 탑재 === 위에서 서술한 바와 같이 탑재된 AP인 A7 프로세서는 최초로 ARMv8[* [[ARM(CPU)|ARM]] 항목에서도 알 수 있듯이 ARMv8의 의의는 단지 64-bit를 지원하는 것뿐 아니라, 명령어의 기반 자체를 완전히 '''갈아엎었다'''는 것에 있다. [[http://jptrans.naver.net/j2k_frame.php/korean/pc.watch.impress.co.jp/docs/column/kaigai/20130918_615784.html|이에 대한 일본 칼럼(번역기)]]] ISA를 사용한 [[Apple Cyclone|Cyclone]] 아키텍처를 내장했다. 또한, [[Apple]]에서도 [[iOS]] 7의 기본 애플리케이션을 모두 64-bit 환경에서 돌아가도록 다시 만들었다고 한다.[* 물론, 32-bit 애플리케이션도 호환모드로 동작할 수 있다.] Apple 자체가 이젠 [[ARM(CPU)|ARM]]과 따로 놀고 자체 CPU 아키텍처를 64-bit용으로 재설계를 했기 때문이다. [[ARM(CPU)|ARM]]의 경우 64-bit CPU 아키텍처인 Cortex-A53, Cortex-A57을 이미 2012년 10월에 공개하긴 했지만, 권장 공정이 20nm로 지금보다 더욱 미세공정을 필요로하기 때문에 실제로 양산화 되어 AP로 탑재되는 시기는 2014년으로 예상되고 있으며 대표적인 라이센스 취득사인 [[삼성전자]]와 [[NVIDIA]]도 로드맵 자체를 2014년에 맞춰서 AP를 개발하는 상황이다. 이에 iPhone 5s가 최초의 64-bit 지원 양산 [[스마트폰]]이라는 타이틀을 가지게 되면서 많은 사람들이 적지 않은 기대감을 내비쳤다. 한편 과거, [[옵티머스 2X]]를 '세계 최초 듀얼코어 스마트폰'으로 마케팅한 [[LG전자]]처럼 Apple 역시 iPhone 5s를 세계 최초 64-bit 스마트폰으로 대대적 홍보하고 있지만 첫 64-bit 지원 [[스마트폰]]이란 의의만 있을 뿐, 이로 인한 실질적인 퍼포먼스 향상은 거의 없을 것이란 의견이 많았'''었'''다.[[http://www.extremetech.com/gaming/166244-iphone-5s-the-64-bit-a7-chip-is-marketing-fluff-and-wont-improve-performance|#]][[http://ryueyes11.tistory.com/2792|사기술적인 측면이 있다는 의견도 있었다.]][* 물론 64-bit로 인한 실질적인 퍼포먼스 향상이 거의 없을 것이란 뜻이지 A7 자체가 A6 대비 퍼포먼스 향상이 없을 거라는 뜻은 아니다.] 다만 이러한 주장들은 iPhone 5s 발표 바로 뒤에 쏟아져 나온 예상들이었고 아무도 실제로 벤치마크 테스트를 해본건 아니었다. 64-bit 지원에 대한 부정적인 예상들은 과거 [[Retina 디스플레이]] 모델이 발표되었을 때의 반응과 비슷한 감이 없잖아 있다. iPhone 5s 정식 발매 이후 벤치마크 결과 iPhone 5에 비해 두 배 정도의 점수를 기록했다. 그리고 iPhone 5s에서 동일한 코드를 64-bit로 재컴파일하여 32-bit와 비교한 벤치마크에서도 비교적 차이가 나는 결과를 보였다. [[http://www.anandtech.com/show/7335/the-iphone-5s-review/4|관련 링크]] 결론적으로 말해서 ARMv8의 64-bit 아키텍처가 성능을 크게 향상시켰다. [[http://minjang.egloos.com/3052820|64bit 벤치마크 분석 블로그]] 이런 이유로 iPhone 5s의 성능 향상은 64-bit지원이 아닌 ARMv8 아키텍처 때문이라는 주장도 있다. 다만, 현실적인 측면에서 보면 더이상 32-bit 기반으로 ARMv8과 같은 개선된 아키텍처를 개발하는 업체가 없기 때문에, '''64-bit CPU도입이 더 빠른 성능을 제공한다'''는 것과 동등한 수준의 의미를 가질 수 있다. 64-bit 이행으로 얻는 다른 장점으로 [[2038년 문제]] 같은 32bit 시스템에서 발견된 여러 가지 사소한 문제를 굳이 손보지 않고도 해결할 수 있다는 것이다. 그리고 4GB 이상의 메모리를 제대로 컨트롤 하기 위해선 64-bit가 필요하지만, 일단 이 부분은 Apple이 1GB만 달고 있기 때문에 해당되지 않는다. 64-bit 시스템이 장점만 있지는 않는데, 일부 애플리케이션의 사용 메모리가 32 bit에 비해 의미가 있는 수준으로 커질 수 있으며,[* 기본적으로 64-bit는 [[포인터]]의 크기가 '''32-bit의 두 배'''이기 때문이다. 포인터는 메모리의 주소를 담는 변수인데, 32비트의 경우 4바이트(0x00000000~0xFFFFFFFF)의 크기를 가지지만 64비트의 경우 8바이트(0x0000000000000000~0xFFFFFFFFFFFFFFFF)의 크기를 가진다.] 이것이 일부 애플리케이션의 퍼포먼스 저하의 원인이 될 수도 있다. 벤치마크에서도 대부분의 경우 64비트로 컴파일한 쪽이 성능이 빨랐지만, 포인터 사용이 많았던 Dijkstra 로직은 메모리 사용량 증가에 따른 캐시 적중률 저하로 32비트에 비해 25% 느린 결과를 보였다. 하지만 일부의 과장된 우려와는 달리 애플리케이션의 크기 자체는 미미한 수준으로 커질 것이는 게 중론이다. 대부분의 앱들의 저장공간을 차지하는 것은 영상, 음성 등의 리소스 데이터이고 이것은 아키텍처에 상관없이 동일하다. 실제 실행코드 부분은 크지 않다. 게다가 64-bit 바이너리의 명령어 크기가 두 배를 차지하는 인텔 x86_64에 비해 ARM의 aarch64는 명령어 크기가 32비트로 이전과 동일하다.[* 이러한 논란은 과거 레티나 디스플레이 모델이 출시되었을 때도 비슷하게 진행된 바 있다. 고해상도를 지원하는 앱은 용량이 몇 배로 커질 것이라 현 iOS 기기의 용량으론 턱없이 부족하다. Retina 디스플레이와 비 Retina 디스플레이 모델 간에 앱 호환성 문제가 생길 것이다라는 식의 억측이었다. 지금 와서 돌이켜보면 결국 헛소리. 그런 거 없었다.] iPhone 5s 직후에는, 애플리케이션의 64-bit 이주가 바로 이루어지지 않기 때문에 호환 모드로 32-bit 애플리케이션들을 돌리면서 제 성능을 다 발휘하지 못하는 상황이 한동안 이어질 것이라는 전망도 있었다. 요컨대 IT 관련 항목에서 자주 인용되는 "붙박이 가구"의 예를 들자면, Microsoft처럼 [[설렁탕을 사왔는데 왜 먹지를 못해|새 집을 사 놓고도 계속 헌 집에서 살아야 하는]] 상황이란 것이다. Windows PC환경에서는 CPU와 칩셋은 64-bit로 준비가 되었음에도 기존에 사용하던 소프트웨어와 주변장치의 호환성 문제가 발생하기도 하고, 32-bit용 애플리케이션을 64-bit용으로 포팅하는 것이 쉽지않은 경우가 있어 그 문제들이 해결될 때까지 혹은 수명이 다 돼서 버릴 때까지 64-bit OS로 바로 이주하지 않고 32-bit를 선택하는 사용자가 많았다. 하위 호환성을 중시하는 마이크로소프트도 모든 사용자들에게 이주를 강요하지 않고 Windows 8을 넘어 Windows 10까지도 32-bit 버전을 제공하며 점진적인 64-bit 이주를 진행하고 있다. 그런데 과거 Mac의 인텔로의 이주 당시의 상황을 현 iOS 기기 상황에 대입해서 보는건 그릇된 대입이라는 의견도 많다. 실제로 그간 iOS 기기에서 하위호환성 문제는 거의 발생하지 않았고, 오히려 호환성 부분에선 iOS 기기에 필적할 만한 경쟁작은 없었다. 이건 Apple이 iOS 기기에 대해 하드웨어나 소프트웨어 둘 다 주도적으로 컨트롤을 하고 있기 때문이고, 사용자가 최소한 소프트웨어적으로는 동등한 경험을 할 수 있게 보장하는 정책 때문이다. iOS 기기의 경우 Apple이 하드웨어를 담당하는 이상 사용자에게 비트 선택권을 주지 않고, 사실 현 상황을 볼 때 그럴 필요도 없다. iPhone 5s는 무조건 64-bit 버전의 iOS 7이 설치가 되며, 사용자가 하위호환성을 원해서 32-bit 버전을 설치하는 것이 불가능하고 굳이 32-bit 버전을 설치해야 할 이유도 없다. 사용자가 하위호환성을 원한다는 건 32-bit와 64-bit 전환에서 불편함이 발생했다는 것인데, iPhone 5s를 사용해본 리뷰어들은 32-bit와 64-bit 앱 구동간에 어떠한 문제도 없다고 밝혔기 때문이다. 현재까지 나온 리뷰들을 종합해볼 때 iPhone 5s에서 64-bit OS로 인한 호환성 문제는 나타나지 않고 있다. 즉, 사용자가 굳이 32-bit를 바랄 이유가 전혀 없다. 그 다음으로 살펴봐야 할 것은 iOS 기기에서 구동되는 소프트웨어, 즉 써드파티 애플리케이션인데 과연 이들이 64-bit로의 빠른 이주를 할 것이냐이다. 일단 iOS 기기는 64-bit 이주를 지연시키는 요소가 PC에 비해 적다. OS와 Apple의 자체 제작 기본 앱은 전부 64-bit 바이너를 포함하고 있다. 그리고 App Store 심사를 이용해 개발자들에게 32/64비트를 동시에 지원하는 팻바이너리[* 하나의 바이너리 파일 안에 두 가지 이상의 플랫폼용 실행코드를 넣어두고, 실행되는 플랫폼 환경에 맞춰 적합한 실행코드가 실행되는 구조를 가리키는 명칭이다. [[OS X]]가 지원하는 유니버설 바이너리도 팻바이너리의 구현방식 중 하나이다.] 형태를 권장하는 방법으로 앱들의 64-bit 이주를 빠르게 하도록 유도할 것이다. 예전에 [[Retina 디스플레이]] 모델 출시 이후 앱들이 속속들이 고해상도에 최적화된 것과 비슷하게 매우 신속하게 이뤄지고 있다. 앱에 따라서 여러 가지 이유로 64-bit 지원을 바로 할 수 없는 경우가 있기 때문에 Apple은 32-bit만 지원하는 앱도 허용하고 있다. Apple이 얼마 지나지 않아 팻바이너리를 강제할 수도 있지만 일단 그것은 시장에 64-bit iOS 기기가 일반화되고 난 후의 일일 것이다. 개발자 입장에서도 큰 부담이 없는 것이, 일부 애플리케이션은 최소한의 소스 수정이나 수정 없이 그대로 간단하게 64-bit 빌드가 가능하기 때문에 64-bit로의 전환은 예상을 뒤엎고 경이로운 속도로 이뤄지고 있다. 일례로 Apple 키노트에서 [[에픽 게임스]]가 자사의 신작 게임인 [[인피니티 블레이드 3]]를 32-bit에서 64-bit로 바꾸는데 '''2시간밖에 안 걸렸다'''고 발표하기도 했다. 물론 성능 때문에 어셈코드 구겨넣은 앱들은 전환에 시간이 걸릴 것으로 보인다. 결론적으로, Apple이 밝힌 것처럼 iOS에서의 64-bit 이주는 PC 시장에 비해 훨씬 더 빠르게 이루어질 것으로 전망된다. 모바일 디바이스에서 [[운영체제]]와 애플리케이션은 매년 발전해나가고 있으며, 그에 따라 요구하는 프로세싱 파워도 늘어나고 있다. 필연적으로 언젠가는 64-bit로 이동할 수밖에 없는 상황이다. 실제로 다른 회사들 역시 64-bit 제품 출시를 준비하고 있는 중이다. 즉, 64-bit를 선택한 Apple의 결정은 모바일 디바이스들이 언젠가는 밟아야할 수순을 먼저 밟은 행동이라고 볼 수 있다. 경쟁사인 퀄컴도 처음에는 부사장급인 고위 임원(CMO)이 직접 '64-bit AP를 갖고 떠들어 대는데 Apple의 64비트 A7칩은 '''마케팅 속임수''' 라고 조롱했으나, 얼마 지나지 않아 발언을 철회하고 회사 차원에서 '[[http://www.zdnet.co.kr/news/news_view.asp?artice_id=20131009082712|64-bit AP는 미래]]'라고 발표했다. 현재 단계에서 64-bit AP가 어떤 이점을 가지는 지는 둘째치고 늦든 빠르든 64-bit AP로 넘어갈 계획을 세우고 있는 퀄컴 입장에서 경솔하게 역풍을 부를 수 있는 발언을 했던 것. 64-bit AP에 대한 갑론을박과 별개로 ARM과 삼성전자 또한 64-bit AP를 설계하고 있으므로 Apple의 64-bit AP를 '마케팅 용어에 불과하다'고 비판하는 것은 매우 경솔한 일이다. 여담으로, 위 발언을 한 고위 임원은 [[http://www.zdnet.co.kr/news/news_view.asp?artice_id=20131024161117|그 자리에서 쫓겨났다]]고 한다. 결론적으로 말해서, Apple이 A7칩을 통해 경이적인 성과를 보인 것은 사실이다. 이는 벤치마크 테스트가 증명하고 있고 그걸 제쳐두고서라도, ARMv8과 64-bit를 그 누구보다 빨리 엔드유저용 제품으로 완성시켰다는 자체가 경쟁사들을 제대로 물먹인 것이기 때문이다. ARM의 로드맵에 따라 예상되던 시기에서 적어도 1년은 빨리 완성되었다는 것이 중론이며, 이것만으로도 Apple의 칩 설계 능력이 삼성이나 퀄컴에 뒤지지 않는 업계 최상위권에 속한다는 것을 증명한것으로 보아도 좋다. A7의 위치는 ARMv8과 64-bit의 다른 AP가 나와봐야 더 정확히 판단할 수 있겠지만, Apple의 첫 자쳬 설계 칩인 A6칩으로부터 단 1년 만에 A7칩을 완성해낼 수 있었다는 것에 매우 높은 평가를 하는 것에는 그다지 큰 문제는 없어보인다. 더 중요한 것은 소프트웨어 쪽인데, 단순히 하드웨어만 64-bit 환경이라면 별 의미 없는 눈속임일 수도 있었다. 하지만 iOS App Store는 PC 소프트웨어 시장과는 사정이 크게 달라서, 과거 고해상도 앱으로의 이주가 그랬듯이 하루가 다르게 신속한 전환이 이뤄지고 있다. 즉, 경쟁사들이 하드웨어적으로 64-bit 지원을 할 때 즈음해서 iOS 기기들은 이미 소프트웨어적으로도 완전한 이주가 완료되었을 상황이라는 것이다.[* 물론 [[안드로이드(운영체제)|경쟁사들이 주로 사용하는 OS]]는 앱 개발 언어가 자바이기 때문에 호환성 문제를 일으킬 소지가 아예 없으므로 그냥 하드웨어만 잘 지원해주면 그만이다. 실제로 일부 네이티브 코드가 들어간 앱 외에는 32-64비트 이주 관련해서 문제가 있는 사례는 극히 드물다.] 주목해야할 부분이 하나 더 있다. Apple의 64-bit A7칩에 대한 업계인들의 반응인데, 위에도 적혀있었듯이 경솔하게 64-bit 전환을 폄하했다가 발언을 철회한 퀄컴 임원의 예를 보듯 64-bit A7칩에 업계인들은 매우 당황했다고 한다. 익명의 한 퀄컴 관계자는 [[http://www.macrumors.com/2013/12/16/qualcomm-employee-64-bit-a7-chip-hit-us-in-the-gut/|#]] "64-bit는 분명 훌륭한 미래지만, 현재의 소프트웨어가 64-bit를 맞을 준비를 하지 못했기에 64-bit로 인한 성능 차이는 없을 것"이라는 사실을 분명히 하면서도, "우리는 입이 딱 벌어졌고, 경악했으며, 준비조차 하지 못했다."고 말해서 A7칩이 업계인들에게 준 충격을 한마디로 정리했다. 또한 "아무도 64-bit이 필수라고 생각하지 않았기 때문에, 64-bit의 로드맵은 Apple의 것에 근접할 수 없다" 라는 코멘트를 통해 Apple의 64-bit 전환이 현재 시점에서 가지는 의미를 설명했다. 일단 64-bit로 전환된 이상 다른 제조사들도 64-bit를 원할 것이며, 지금 64-bit AP가 준비된 곳은 Apple 이외에는 존재하지 않아 64-bit AP에 대한 압박이 업계에 가해질 것이라는 것이다. 이 관계자는 Apple이 64-bit A7칩을 통해 '''"우리 모두를 고자로 만들어버렸다."''' 고 전했다. 2013년 12월, Apple은 개발자들에게 2014년 2월부터는 제출되는 모든 앱을 iOS 7에 최적화시켜야 한다고 공지했다. 이후 2015년 2월부터 App Store 심사를 받는 모든 애플리케이션에 64비트 지원을 의무화했다. iOS의 64비트 전환이 마무리 단계에 이르른 셈. 이후 2017년, [[iOS 11]]부터는 '''32비트 앱을 지원하지 않는다.''' iOS 11이 출시되면서 모든 32비트 호환 레이어가 삭제되었으며, 고작 4년 만에 64비트로의 이주가 완료되었다. PC와 모바일의 환경 차이가 있다고 하더라도 경이로운 속도이다.저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기